Memory system and method for controlling nonvolatile memory

ABSTRACT

According to one embodiment, a memory system receives a write request specifying a first logical address to which first data is to be written, and a length of the first data, from a host. The memory system writes the first data to a nonvolatile memory, and stores a first physical address indicating a physical storage location on the nonvolatile memory to which the first data is written, and the length of the first data, in an entry of a logical-to-physical address translation table corresponding to the first logical address. When the memory system receives a read request specifying the first logical address, the memory system acquires the first physical address and the length from the address translation table, and reads the first data from the nonvolatile memory.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 15/820,573,filed Nov. 22, 2017 and is based upon and claims the benefit of priorityfrom Japanese Patent Application No. 2017-135785, filed Jul. 11, 2017,the entire contents of which are incorporated herein by reference.

FIELD

Embodiments described herein relate generally to a nonvolatile memorycontrol technology.

BACKGROUND

Recently, memory systems including nonvolatile memories have been widelyused as main storages of various information processing devices. As oneof the memory systems, NAND flash technology-based solid-state drives(SSD) are known.

In a memory system such as an SSD, address translation for translating alogical address into a physical address of a nonvolatile memory isexecuted by using an address translation table.

In a normal address translation table, physical addresses correspondingto logical addresses are managed, respectively.

However, in a normal SSD, data corresponding to one logical address isfixed-length data, and arbitrary-length data cannot be written to anarbitrary logical address.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing an example of the configuration of amemory system according to an embodiment.

FIG. 2 is a diagram showing an example of the configuration of avariable-length lookup table managed by the memory system of theembodiment.

FIG. 3 is a diagram showing an example of the configuration of afixed-length lookup table.

FIG. 4 is a diagram showing an example of a variable-length data writerequest applied to the memory system of the embodiment.

FIG. 5 is a diagram showing an example of a variable-length data readrequest applied to the memory system of the embodiment.

FIG. 6 is a sequence diagram showing the procedure of a write operationexecuted by the memory system of the embodiment.

FIG. 7 is a diagram showing the relationship between a free block pool,an active block pool and a write destination block managed by the memorysystem of the embodiment.

FIG. 8 is a diagram showing another example of the configuration of thevariable-length lookup table managed by the memory system of theembodiment.

FIG. 9 is a sequence diagram showing the procedure of a read operationexecuted by the memory system of the embodiment.

FIG. 10 is a diagram showing another example of the configuration of thevariable-length lookup table managed by the memory system of theembodiment.

FIG. 11 is a diagram showing an example of the configuration of ahierarchical lookup table (multilevel lookup table) managed by thememory system of the embodiment.

FIG. 12 is a block diagram showing an example of the hardwareconfiguration of the memory system of the embodiment.

FIG. 13 is a block diagram showing the relationship between a NANDinterface and a plurality of NAND flash memory chips in the memorysystem of the embodiment.

FIG. 14 is a diagram showing an example of the configuration of alogical block (superblock) used in the memory system of the embodiment.

FIG. 15 is an explanatory diagram showing a plurality of regionsacquired by logically dividing a nonvolatile memory of the memory systemof the embodiment.

FIG. 16 is a block diagram showing the relationship between theplurality of regions, logical address spaces corresponding to theregions and lookup tables corresponding to the regions in the memorysystem of the embodiment.

DETAILED DESCRIPTION

Various embodiments will be described hereinafter with reference to theaccompanying drawings.

In general, according to one embodiment, a memory system connectable toa host includes a nonvolatile memory and a controller electricallyconnected to the nonvolatile memory and configured to control thenonvolatile memory. The controller is configured to manage alogical-to-physical address translation table including a plurality ofentries corresponding to a plurality of logical addresses. Thecontroller is configured to receive a write request specifying a firstlogical address to which first data is to be written, and a length ofthe first data, from the host. The controller is configured to write thefirst data to the nonvolatile memory, and to store a first physicaladdress indicating a physical storage location on the nonvolatile memoryto which the first data is written, and the length of the first data, inthe entry of the logical-to-physical address translation tablecorresponding to the first logical address. The controller isconfigured, when receiving a read request specifying the first physicaladdress from the host, to acquire the first physical address and thelength from the logical-to-physical address translation table, and toread the first data from the nonvolatile memory based on the acquiredfirst physical address and the acquired length.

Firstly, the configuration of an information processing system 1including a memory system according to an embodiment will be describedwith reference to FIG. 1.

This memory system is a semiconductor storage device configured to writedata to a nonvolatile memory and read data from the nonvolatile memory.This memory system may be realized as a solid-state drive (SSD) 3including a NAND flash memory.

The information processing system 1 may include a host (host device) 2and the SSD 3. The host 2 is an information processing device (computingdevice) which accesses the SSD 3. The host 2 may be a server computerwhich executes various user application programs or may be a personalcomputer. The SSD 3 can be used as the main storage of the informationprocessing device functioning as the host 2. The SSD 3 may be built inthis information processing device or may be connected to thisinformation processing device via a cable or network.

As the interface for connecting the host 2 and the SSD 3 to each other,SCSI, Serial Attached SCSI (SAS), ATA, Serial ATA (SATA), PCI Express(PCIe), Ethernet (registered trademark), Fibre Channel, NVM Express(NVMe) (registered trademark), etc., can be used.

The host 2 includes a variable-length data read/write module 101. Thevariable-length data read/write module 101 may be realized as softwarewhich operates on the host 2 (for example, the server computer). Forexample, in the case of using the SSD 3 to store a file or store datafor a block device, the variable-length data read/write module 101 maybe realized as part of an operating system executed by the host 2 or maybe realized as part of a device driver executed by the host 2.Alternatively, the variable-length data read/write module 101 may berealized as part of a specific application program.

The SSD 3 includes a controller 4 and a nonvolatile memory (NAND flashmemory) 5. The controller 4 is a memory controller which controls theNAND flash memory 5 and may be realized by a circuit referred to as asystem LSI (referred to also as a “control circuit” or a “processingcircuit”), for example.

The SSD 3 further may include a random access memory (RAM) 6. The RAM 6may be a DRAM connected to the controller 4 or may also be an SRAM builtin the controller 4.

The controller 4 includes a host request processing module 21 and avariable-length lookup table (LUT) management module 22. Each of thehost request processing module 21 and the variable-length LUT managementmodule 22 may be realized by firmware executed by a CPU in thecontroller 4. Alternatively, all or part of each of the host requestprocessing module 21 and the variable-length LUT management module 22may be realized by hardware in the controller 4.

The regions (storage regions) in the NAND flash memory 5 can begenerally classified into a data region 5A and a management region 5B.The data region 5A is a region for storing data (user data) from thehost 2. The management region 5B is a region for storing managementinformation for managing an operation of the SSD 3. As the example ofthe management information, variable-length lookup table (LUT) 32 isincluded.

The variable-length LUT 32 is a logical-to-physical address translationtable including a plurality of entries corresponding to a plurality oflogical addresses, and is used for managing correspondences between aplurality of logical addresses and a plurality of physical addresses onthe NAND flash memory 5. The variable-length LUT 32 is stored in themanagement region 5B of the NAND flash memory 5. To increase the speedof read/write access to the variable-length LUT 32, a copy of part orall of the variable-length LUT 32 may be stored in the RAM 6 as a cache(logical-to-physical address translation table cache). Another part ofthe region of the RAM 6 may be used as a write buffer 31 for temporarilystoring write data.

To improve the efficiency of a write operation to the NAND flash memory5, which is a nonvolatile memory where a write order is restricted, itis necessary to dynamically change the correlation between a logicalstorage location (logical address) specified by the host 2 and aphysical storage location (physical address) on the NAND flash memory 5.Therefore, in general, the correlations between logical addresses andphysical addresses are managed, respectively, by a lookup table(logical-to-physical address translation table). In the case of writingdata, the lookup table is updated, and the physical storage location(physical address) on the NAND flash memory 5 to which the data iswritten is associated with the logical address specified by the host. Inthe case of reading data, the lookup table is referred to, and thephysical storage location (physical address) on the NAND flash memory 5from which the data to be read is stored is acquired from the lookuptable. A logical block address (LBA) may be used as the logical address,for example.

A normal lookup table manages the correlations between LBAs and physicaladdresses, respectively, in fixed-length units (for example, in 4 KBunits). It is because an existing SSD provides an LBA, which is derivedfrom a fixed-length sector of a hard disk, as an interface. Therefore,in the existing SSD, data which can be written to a logical storagelocation corresponding to one LBA is limited to fixed-length data. Thefixed-length data means that the length of data corresponding to onelogical address is fixed. For example, if one logical address (forexample, one LBA) indicates a logical sector with a fixed-length (forexample, 4 KBytes), data which can be written to a physical storagelocation corresponding to this LBA is limited to fixed-length datahaving this fixed size (for example, 4 KBytes). This interface issufficient when the user wishes to store fixed-size data, i.e.,fixed-length data to one logical address.

However, in the case of a system which handles variable-length data, ahost needs to execute processing for converting variable-length data tofixed-length data, processing for managing metadata indicating whichvariable-length data is stored, in which fixed-length data thevariable-length data is stored, and in which location in thefixed-length data the variable-length data is stored, etc.

The variable-length data means that the length of data corresponding toone logical address is variable.

For example, the length of a value is variable in a key-value storesystem. Further, in a case where a host compresses data and stores thecompressed data in an SSD, the length of the compressed data variesdepending on the compression ratio. In a case where an SSD has acompression function, the length of compressed data also varies.

Therefore, in such a system, a host needs to execute complicatedprocessing such as (1) processing for dividing large variable-lengthdata into fixed-length data portions (block data portions), (2)processing for integrating small variable-length data portions or addingdummy data to small variable-length data, and converting the smallvariable-length data to fixed-length data, and (3) processing forseparately managing metadata indicating which variable-length data isstored, in which fixed data the variable-length data is stored, and inwhich location in the fixed data the fixed-length data is stored.

Further, also in a normal file system, since a file size varies fromfile to file, the above-described complicated processing needs to beexecuted.

This processing leads to inefficiency such as (1) an increase of theprocessing time of the CPU of the host, (2) an increase of the memoryaccess time by reading/writing metadata, (3) an increase of theconsumption of a memory resource by wring metadata/dummy data, (4) anincrease of write amplification by the increase of the consumption ofthe memory resource, and (5) a reduction of the lifespan of the SSD bythe increase of write amplification.

In the present embodiment, the SSD 3 is configured to store informationindicating from which physical storage location on the NAND flash memory5 data is stored and in what length the data is stored thereon, in thevariable-length LUT 32, and in this way, arbitrary-length data can bestored at an arbitrary logical address. In other words, according to thevariable-length LUT 32, a physical storage region having a sizecorresponding to an arbitrary data length specified by the host 2 can beallocated to a logical storage location in the SSD 3 corresponding to acertain logical address. Therefore, even in the case of writingvariable-length data smaller than fixed-length data, thisvariable-length data can be written to an arbitrary logical addresswithout executing the processing for adding dummy data to thisvariable-length data and converting this variable-length data tofixed-length data. Therefore, it is possible to allocate only a physicalstorage region necessary for storing data in the NAND flash memory 5.

Generally, if a storage system configured to store variable-length datain such a manner is achieved, the following problems arise when the sizeof previous data (old data) corresponding to a certain LBA and the sizeof new data (updated data) corresponding to this LBA are different fromeach other: (1) the new data does not fit in the region in which theprevious data has been stored, (2) an empty space is created in part ofthe region in which the previous data has been stored, etc. Therefore,in a normal film system, in many cases, write data is divided intofixed-length data portions and the fixed-length data portions are storedin a storage by executing the previously-described complicatedprocessing.

However, in the NAND flash memory 5, data can only be written from thebeginning of a block in the NAND flash memory 5. Therefore, in the caseof updating data, old data is left in an original physical storagelocation and new data is written to another physical storage location,and the old data will be erased by garbage collection when necessary.Therefore, in an SSD which writes data to the NAND flash memory 5, theabove-described problems that (1) new data does fit in a region in whichprevious data is stored and (2) an empty space is created in part of theregion in which the previous data is stored will not occur in the firstplace. This can be said to be unique characteristics of a system whichmanages variable-length data using a nonvolatile memory where a writeorder is restricted.

In the information processing system 1 shown in FIG. 1, thevariable-length data read/write module 101 of the host 2 requests theSSD 3 to write or read variable-length data. As described above,variable-length data means that the length of data corresponding to onelogical address is variable. A variable-length data write requestspecifies a logical address to which data (write data) is to be writtenand a length of the write data (that is, the length of the data to bewritten to the logical address). A variable-length data read request mayonly specify a logical address of data to be read.

In the SSD 3, the host request processing module 21 of the controller 4receives a write request from the host 2. The host request processingmodule 21 writes write data (variable-length data Dx) received from thehost 2 to the NAND flash memory 5.

More specifically, the host request processing module 21 writes thewrite data (variable-length data Dx) to a current write destinationblock allocated from a group of free blocks of the NAND flash memory 5.

Subsequently, in cooperation with the variable-length LUT managementmodule 22, the host request processing module 21 stores a physicaladdress indicating a physical storage location on the NAND flash memory5 to which the write data (variable length data Dx) is written, and adata length (write data length) specified by the write request, in anentry in the variable-length LUT 32 corresponding to a logical addressspecified by the write request.

If receiving a read request specifying this logical address from thehost 2, the host request processing module 21 acquires, from thevariable-length LUT 32, the physical address indicating the physicalstorage location on the NAND flash memory 5 in which the variable-lengthdata Dx is stored, and the data length of the variable-length data Dx.The physical storage location in which the variable-length data Dx isstored is the starting location of the region in the NAND flash memory 5in which the variable-length data Dx is stored. Based on the acquiredphysical address and the acquired data length, the host requestprocessing module 21 reads the variable-length data Dx from the NANDflash memory 5 and returns the read variable-length data Dx to the host2.

FIG. 2 shows an example of the configuration of the variable-length LUT32.

The variable-length LUT 32 includes the same number of LUT entries asthe number of logical addresses (for example, here, LBA 0 to LBA max).The LUT entries are associated with the LBAs, respectively. Each LUTentry may include a location field for managing a location (physicalstorage location) on the NAND flash memory 5 in which data is stored,and a length field for managing a length of the data.

The location on the NAND flash memory 5 may be represented by a physicaladdress (PBA) indicating a block number and a location in the block. Theblock number indicates a block in the NAND flash memory 5 to which thedata is written. The location in the block indicates a location in theblock (offset position in the block) to which the data is written.

The location in the block may be represented by the number of bytes fromthe beginning of the block to the location in the block. In this way, alocation in a block can be managed in small granularity, i.e., in byteunits, and as a result, data can be densely arranged in the NAND flashmemory 5. As a matter of course, to reduce the amount of data needed tobe stored in the LUT entry, the location in the block may be managed insuch granularity as 256-byte units, for example.

Alternatively, the location on the NAND flash memory 5 may berepresented by a physical address (PBA) indicating a block number, apage number in the block, and a location in the page. The page number inthe block indicates the first page to which the data is written. Thelocation in the page indicates the location in the page (offset locationin the page) to which the data is written.

The location in the page may be represented by the number of bytes fromthe beginning of the page to the location in the page. In this way, datacan be densely arranged in the NAND flash memory 5. As a matter ofcourse, to reduce the amount of data needed to be stored in the LUTentry, the location in the page may be managed in such granularity as256-byte units, for example.

In an LUT entry corresponding to a logical address to which data is notwritten, a predetermined constant value (e.g., null) may be stored as alocation.

The length of data specified by a write request may also be representedby the number of bytes or may also be represented in units such as256-byte units.

As shown in FIG. 2, if variable-length data D11 corresponding to the LBA9 is written to a region starting from the beginning of a block BLK1, aphysical address (PBA) indicating a starting location X1 of the blockBLK1, and a length of the variable-length data D11 (here, the length isrepresented as “5”) are stored in an LUT entry corresponding to the LBA9.

If variable-length data D12 corresponding to the LBA 0 is written to aregion starting from a location X2 of the block BLK1, a physical address(PBA) indicating the location X2, and a length of the variable-lengthdata D12 (here, the length is represented as “7”) are stored in an LUTentry corresponding to the LBA 0. The location X2 may be a location inthe block BLK1 which is derived by addition of the length of thevariable-length data D11 to the location X1.

If variable-length data D13 corresponding to the LBA 12 is written to aregion stating from a location X3 of the block BLK1, a physical addressindicating the location X3, and a length of the variable-length data D13(here, the length is represented as “2”) are stored in an LUT entrycorresponding to the LBA 12. The location X3 may be a location in theblock BLK1 which is derived by addition of the length of thevariable-length data D12 to the location X2.

If variable-length data D21 corresponding to the LBA 3 is written to aregion starting from the beginning of a block BLK2, a physical addressindicating a starting location Y1 of the block BLK2, and a length of thevariable-length data D21 (here, the length is represented as “3”) arestored in an LUT entry corresponding to the LBA 3.

If variable-length data D22 corresponding to the LBA 7 is written to aregion starting from a location Y2 of the block BLK2, a physical addressindicating the location Y2 of the block BLK2, and a length of thevariable-length data D22 (here, the length is represented as “9”) arestored in an LUT entry corresponding to the LBA 7.

The variable-length LUT 32 may be realized by a multilevel addresstranslation table (hierarchical LUT) including a plurality ofhierarchical tables. In this case, instead of securing a regionnecessary for storing the whole variable-length LUT 32 on the NAND flashmemory 5 or the RAM 6, it is only necessary to secure a region necessaryfor storing table data portions in the variable-length LUT 32corresponding respectively to logical address ranges in which data areactually stored on the NAND flash memory 5 or the RAM 6. Therefore, itis not necessary to allocate a physical resource for storing addresstranslation information corresponding to a logical address range inwhich data is not stored. For this reason, the use of the hierarchicalLUT is especially beneficial to such a system as a key-value store wherevariable-length data are coarsely arranged.

Generally, it is desired that not only variable-length data but alsofixed-length data are read and written. Therefore, instead of managingthe whole SSD 3 by one LUT, a plurality of LUTs may be provided, and afixed-length LUT and a variable-length LUT may be used in combination.The SSD 3 may have a multi-namespace control function. With themulti-namespace control function, to handle one storage device as if itwere a plurality of drives, a plurality of logical address spaces (LBAspaces) can be allocated to the SSD 3. A plurality of namespaces canfunction as if they were a plurality of independent SSDs (virtual SSDs).When the host 2 requests the SSD 3 to create a namespace, the host 2 mayspecify a type of a namespace to be created (a namespace of a type #1for handling fixed-length data or a namespace of a type #2 for handlingvariable-length data).

A plurality of LUTs corresponding to a plurality of namespaces aremanaged in the SSD 3. The LUT for each namespace of the type #2 forhandling the variable-length data is realized by the variable-length LUT32. The LUT for each namespace of the type #1 for handling thefixed-length data is realized by a fixed-length LUT 33 shown in FIG. 3.

In the namespace of the type #1, the length of data storable in thelogical storage location corresponding to one LBA is fixed. In FIG. 3,it is assumed that the length of data storable in the logical storagelocation corresponding to one LBA is 4 KBytes (4 KB).

As shown in FIG. 3, the fixed-length LUT 33 includes the same number ofLUT entries as the number of logical addresses (for example, here, LBA 0to LBA max). The LUT entries are associated with the LBAs, respectively.In each LUT entry, a location (physical address (PBA)) on the NAND flashmemory 5 in which data is stored is stored.

Locations (physical storage locations) on the NAND flash memory 5managed in the fixed-length LUT 33 are locations aligned with 4 KBytesboundaries.

If 4 KB data corresponding to the LBA 9 is written to a 4 KB regionstarting from the beginning of a block BLK11, a physical addressindicating a starting location X11 of the block BLK11 is stored in anLUT entry corresponding to the LBA 9.

If 4 KB data corresponding to the LBA 0 is written to a 4 KB regionstarting from a location X12 of the block BLK11, a physical addressindicating the location X12 is stored in an LUT entry corresponding tothe LBA 0.

If 4 KB data corresponding to the LBA 12 is written to a 4 KB regionstarting from a location X13 of the block BLK11, a physical addressindicating the location X13 is stored in an LUT entry corresponding tothe LBA 12.

If 4 KB data corresponding to the LBA 3 is written to a 4 KB regionstarting from the beginning of a block BLK12, a physical addressindicating a starting location Y11 of the block BLK 12 is stored in theLUT entry corresponding to the LBA 3.

If 4 KB data corresponding to the LBA 7 is written to a 4 KB regionstarting from a location Y12 of the block BLK12, a physical addressindicating the location Y12 of the block BLK12 is stored in an LUT entrycorresponding to the LBA 7.

FIG. 4 shows a normal write request (normal write command) and avariable-length write request (variable-length data write command).

The normal write command requests the SSD 3 to write fixed-length datawhere the length of data per logical address is fixed.

As shown in the upper part of FIG. 4, the normal write command includesa parameter specifying a starting LBA and a parameter specifying anumber of logical sectors. The starting LBA is the address of thelogical sector to which data is to be written first. The number oflogical sectors indicates the number of logical sectors to which data isto be written, i.e., the number of LBAs corresponding to the write data.The size of write data which the host 2 can transmit to the SSD 3 islimited to a multiple of the fixed length (for example, a multiple of 4KB).

The variable-length data write command requests the SSD 3 to writevariable-length data where the length of data per logical address isvariable.

As shown in the lower part of FIG. 4, the variable-length data writecommand includes a parameter specifying a logical address, and aparameter specifying a data length. The logical address is the addressof one logical storage location (variable-length logical storagelocation) to which data (variable-length data) is to be written. Thedata length indicates the length of data to be written to one logicalstorage location. The data length can be specified in units smaller thanthe length of the fixed-length data (for example, 4 KB) such as byteunits or can also be specified in such units as 256-byte units.

FIG. 5 shows a normal read request (normal read command) and avariable-length data read request (variable-length data read command).

The normal read command requests the SSD 3 to read fixed-length datawhere the length of data per logical address is fixed.

As shown in the upper part of FIG. 5, the normal read command includes aparameter specifying a starting LBA and a parameter specifying thenumber of logical sectors. The starting LBA is the address of thelogical sector from which data is to be read first. The number oflogical sectors indicates the number of logical sectors from which datato be read, i.e., the number of LBAs corresponding to the data to beread. The size of data which the host 2 can read from the SSD 3 islimited to a multiple of the fixed length (for example, a multiple of 4KB).

The variable-length data read command requests the SSD 3 to readvariable-length data where the length of data per logical address isvariable.

As shown in the lower part of FIG. 5, the variable-length data readcommand includes a parameter specifying a logical address (for example,an LBA). The logical address (for example, the LBA) is the address ofone logical storage location (variable-length logical storage location)from which data (variable-length data) is to be read. Thevariable-length data stored in the one logical storage location (thelength of the data is managed by the variable-length LUT 32) is readfrom the NAND flash memory 5.

As the variable-length data write request and the variable-length dataread request, a new expanded write command and a new expanded readcommand where a write command and a read command standardized by anexisting protocol such as NVMe or SCSI are expanded can be used.Alternatively, a unique protocol may be developed for thevariable-length data write request and the variable-length data readrequest.

FIG. 6 is a sequence diagram showing the procedure of a write operation.

If the host 2 wishes to write variable-length data, the variable-lengthdata read/write module 101 transmits a variable-length data writerequest specifying a logical address to which write data(variable-length data) is to be written and a length (data length) ofthe write data, to the SSD 3. The write request may further includewrite data, or in place of write data, the write request may furtherinclude only a parameter indicating a location on a host memory (memoryin the host 2) in which the write data exists.

When the host request processing module 21 of the SSD 3 receives thevariable-length data write request from the host 2, the host requestprocessing module 21 writes the logical address, the data length and thewrite data, to the write buffer 31 (Step S11). Subsequently, the hostrequest processing module 21 returns a command completion responseincluding a return value indicating whether processing is normallyexecuted in response to the write request or not, to the host 2.

After that, at an appropriate time (for example, a time when the writebuffer 31 is filled with data to be written, a time when a certain timepasses after the write request is received, a time when a flash commandrequesting a write of data, which is not written to the NAND flashmemory 5, to the NAND flash memory 5 is received from the host 2, etc.),the host request processing module 21 writes the write data of the writebuffer 31 to the data region 5A of the NAND flash memory 5 (Step S12).In Step S12, the write data is written to a region starting from thenext available physical storage location in the current writedestination block.

The next available physical storage location in the current writedestination block may be managed by the variable-length LUT managementmodule 22. The variable-length LUT management module 22 determines aphysical storage location to which the write data is to be written suchthat data is arranged in order from the beginning of the currentdestination block. If the length of write data is greater than thecapacity of the remaining available region of the current destinationblock, one free block is selected from a group of free blocks in theNAND flash memory 5, and the selected free block is allocated as a newwrite destination block. In Step S12, the host request processing module21 may notify the logical address and the data length specified by thewrite request to the variable-length LUT management module 22, and mayacquire the physical storage location on the NAND flash memory 5 towhich the write data to be written from the variable-length LUTmanagement module 22.

Next, a physical address indicating the physical storage location on theNAND flash memory 5 to which the write data is written and a length ofthe write data are stored in an LUT entry (Step S13). This processingmay be executed by the variable-length LUT management module 22.

Instead of returning a command completion response to the host 2immediately after executing the processing of Step S11, a commandcompletion response may be returned to the host 2 immediately after theprocessing of Step S13 is executed.

Further, to avoid wasting the write destination block or to handle writedata (variable-length data) greater than the capacity of one block, aplurality of locations and a plurality of lengths may be stored in oneLUT entry of the variable-length LUT 32 such that the write data(variable-length data) can be written across a plurality of blocks.

Still further, if new variable-length data is overwritten to a physicaladdress to which variable-length data is already written, previousvariable-length data will be invalidated. If the number of free blocksis reduced to a certain number or less, garbage collection (GC) isexecuted with respect to some blocks containing a large volume ofinvalidated data. In the GC, only valid data in these blocks (GC sourceblocks) containing a large volume of invalidated data are copied to a GCdestination block (free block), and these GC source blocks are changedto free blocks, accordingly.

FIG. 7 shows the relationship between an active block pool 51, a freeblock pool 52 and a write destination block managed by the controller 4of the SSD 3.

The state of each block is generally classified into an active blockwhich stores valid data and a free block which does not store validdata. Each block as the active block is managed by a list referred to asthe active block pool 51. On the other hand, each block as the freeblock is managed by a list referred to as the free block pool 52.

In the present embodiment, the controller 4 allocates one block (freeblock) selected from the free block pool 52 as a write destination blockto which write data received from the host 2 is to be written. In thiscase, the controller 4 firstly executes an erase operation to theselected block (free block), and changes the block to an erased statewhere data can be written, accordingly. If the current write destinationblock is completely filled with write data from the host 2, thecontroller 4 moves the current write destination block to the activeblock pool 51, and allocates one new block (free block) from the freeblock pool 52 as a new write destination block.

If all valid data in a certain block in the active block pool 51 isinvalidated by data update, unmapping, garbage collection, etc., thecontroller 4 moves the block to the free block pool 52.

FIG. 8 shows another example of the configuration of the variable-lengthLUT 32.

The variable-length LUT 32 is configured to store a plurality oflocations and a plurality of lengths. In FIG. 8, the variable-length LUT32 has such a configuration that two locations and two lengths can bestored in each LUT entry such that certain write data (variable-lengthdata) can be written across two blocks. Note that the number oflocation-and-length sets stored in each LUT entry is not limited to twoand may be three or more.

If variable-length data D100 corresponding to the LBA 9 is written to aregion starting from the beginning of a block BLK1, a physical addressindicating a starting location X1 of the block BLK1 and a length of thevariable-length data D100 (here, the length is represented as “5”) arestored in an LUT entry corresponding to the LBA 9.

If the length of variable-length data D101 corresponding to the LBA 0 isgreater than the size of the remaining region of the block BLK1, onlypart of the variable-length D101 (variable-length data D101A) is writtento a region starting from a location X2 of the block BLK1. In this case,a physical address indicating the location X2 and a length of thevariable-length data D101A (here, the length is represented as “12”) arestored in an LUT entry corresponding to the LBA 0. The remaining part ofthe variable-length data D101 (variable-length data D101B) is written toanother block BLK2. If the variable-length data D101B is written to aregion starting from the beginning of the block BLK2, a physical addressindicating a starting location Y1 of the block BLK2 and a length of thevariable-length data D101B (here, the length is represented as “3”) arefurther stored in the LUT entry corresponding to the LBA 0.

That is, the host request processing module 21 firstly compares thelength of the variable-length data D101 specified by the write request,with the size of the remaining region of the block BLK1. The block BLK1is the current write destination block. If the length of thevariable-length data D101 exceeds the size of the remaining region ofthe block BLK1, the host request processing module 21 divides thevariable-length data D101 into the variable-length data D101A and thevariable-length data D101B. The variable-length data D101A is datahaving a data length corresponding to the size of the remaining regionof the block BLK1. The variable-length data D101B is data remaining inthe variable-length data D101. The host request processing module 21writes the variable-length data D101A to the block BLK1 and writes thevariable-length data D101B to the block BLK2 allocated as a new writedestination block. Subsequently, the host request processing module 21updates the variable-length LUT 32, and stores the physical addressindicating the location (physical storage location) X2 to which thevariable-length data D101A is written, the length of the variable-lengthdata D101A, the physical address indicating the location (physicalstorage location) Y1 to which the variable-length data D101B is written,and the length of the variable-length data D101B, in the LUT entrycorresponding to the LBA 0.

If receiving a read request specifying the LBA 0, the host requestprocessing module 21 acquires the physical address indicating thelocation X1 in which the variable-length data D101A is stored, thelength of the variable-length data D101A, the physical addressindicating the location Y1 in which the variable-length data D101B isstored, and the length of the variable-length data D101B, from thevariable-length LUT 32. Subsequently, the host request processing module21 reads the variable-length data D101A and the variable-length dataD101B, respectively, from the block BLK1 and the block BLK2, combinesthe variable-length data D101A with the variable-length data D101B, andreproduces the data D101, and then returns the reproduced data D101 tothe host 2.

FIG. 9 is a sequence diagram showing the procedure of a read operation.

If the host 2 wishes to read variable-length data, the variable-lengthread/write module 101 transmits a read request specifying a logicaladdress corresponding to the variable-length data, to the SSD 3.

When the host request processing module 21 of the SSD 3 receives thevariable-length data read request from the host 2, the host requestprocessing module 21 refers to the variable-length LUT 32 and acquires aphysical address indicating a location (physical storage location) onthe NAND flash memory 5 and a length of the variable-length data, froman LUT entry corresponding to the logical address specified by the readrequest (Step S21). In Step S21, the host request processing module 21may transmit the logical address specified by the read request to thevariable-length LUT management module 22 and may inquire thevariable-length LUT management module 22 about the location on the NANDflash memory 5 and the length of data to be read.

The host request processing module 21 reads data from the NAND flashmemory 5 based on the acquired physical address and the acquired datalength (Step S22). In Step S22, the host request processing module 21reads the data stored in a region on the NAND flash memory 5 which isspecified by the acquired physical address and the acquired data length,from the NAND flash memory 5.

Subsequently, the host request processing module 21 returns the readdata, the data length and a command completion response to the host 2.

FIG. 10 shows another example of the configuration of thevariable-length lookup table 32.

In the variable-length LUT 32 shown in FIG. 10, a key of a key-valuestore is used as the logical address indicating the logical storagelocation of the SSD 3. The logical address included in the write/readrequest transmitted from the host 2 to the SSD 3 indicates a certainkey.

Each LUT entry of the variable-length LUT 32 includes a key field formanaging a key specified by the host 2, a location field for managing alocation (physical storage location) on the NAND flash memory 5 in whichvariable-length data (a value alone or a key-value pair) correspondingto the key is stored, and a length field for managing a length of thevariable-length data.

If variable-length data D11 corresponding to a key “DDD” is written to aregion starting from the beginning of a block BLK1, the key “DDD”, aphysical address indicating a starting location X1 of the block BLK1,and a length of the variable-length data D11 (here, the length isrepresented as “5”) are stored in an LUT entry.

If variable-length data D12 corresponding to a key “AAA” is written to aregion starting from a location X2 of the block BLK1, the key “AAA”, aphysical address indicating the location X2, and a length of thevariable-length data D12 (here, the length is represented as “7”) arestored in an LUT entry.

If variable-length data D13 corresponding to a key “XXX” is written to aregion starting from a location X3 of the block BLK1, the key “XXX”, aphysical address indicating the location X3, and a length of thevariable-length data D13 (here, the length is represented as “2”) arestored in an LUT entry.

If variable-length data D21 corresponding to a key “BBB” is stored in aregion starting from the beginning of a block BLK2, the key “BBB”, aphysical address indicating a starting location Y1 of the block BLK2,and a length of the variable-length data D21 (here, the length isrepresented as “3”) are stored in an LUT entry.

If variable-length data D22 corresponding to a key “CCC” is written to aregion starting from a location Y2 of the block BLK2, the key “CCC”, aphysical address indicating the location Y2 of the block BLK2, and alength of the variable-length data D22 (here, the length is representedas “9”) are stored in an LUT entry.

In the case of using the variable-length LUT 33 shown in FIG. 10, basedon a key included in a read request or a write request, an LUT entrycorresponding to the key is searched. Then, the searched LUT entry isreferred to or updated. In the case of writing data, if an LUT entrycorresponding to a key included in a write request does not exist, aphysical address indicating a physical storage location on the NANDflash memory 5 to which variable-length data corresponding to the key iswritten, and a length of the variable-length data are stored in anunused LUT entry.

FIG. 11 shows an example of the configuration of a hierarchical lookuptable (multilevel lookup table).

The hierarchical lookup table shown in FIG. 11 includes a plurality ofhierarchical tables. These tables are used for multistagelogical-to-physical address translation. The number of tables includedin the hierarchical lookup table corresponds to the number of stages inthe logical-to-physical address translation. The number of tablesincluded in the hierarchical lookup table may be two (the number ofstages in the address translation may be two), may be three (the numberof stages in the address translation may be three), or may be four ormore (the number of stages in the address translation stages may be fouror more).

For example, the hierarchical lookup table may be a three-level addresstranslation table for translating a logical address into a physicaladdress by three-stage address translation. In this case, thehierarchical lookup table may include hierarchical three tables usedrespectively in three address translation stages, namely, a level 1table (L1 table) 73, a level 2 table (L2 table) 72 and a level 3 table(L3 table) 71.

The L3 table 71 is an address translation table including a plurality ofLUT entries corresponding to logical addresses, respectively. The L3table 71 includes a plurality of data portions (a data portion #0, adata portion #1, . . . , a data portion #128, . . . ). In other words,the L3 table 71 is divided into these data portions (the data portion#0, the data portion #1, . . . , the data portion #128, . . . ). Thesedata portions have the same fixed size.

One data portion (table data portion) of the L3 table 71 can include 128LUT entries (that is, 128 physical addresses and 128 data lengths), forexample. That is, one LBA is covered by one LUT entry in the L3 table71.

The locations on the NAND flash memory 5 in which the data portions (thedata portion #0, the data portion #1, . . . , the data portion #128, . .. ) of the L3 table 71 are stored are individually managed by the L2table 72.

The L2 table 72 also include a plurality of data portions (a dataportion #0, a data portion #1, . . . , a data portion #128, . . . )having the same fixed size as the data portions of the L3 table 71. Inother words, the L2 table 72 is divided into these data portions (thedata portion #0, the data portion #1, . . . , the data portion #128, . .. ).

Each data portion of the L2 table 72 includes a plurality of LUTentries, for example, 128 LUT entries. Each LUT entry shows a locationon the NAND flash memory 5 in which one data portion in the L3 table 71is stored. That is, 128 LBAs are covered by one LUT entry in the L2table 72.

The locations on the NAND flash memory 5 in which the data portions (thedata portion #0, the data portion #1, . . . , the data portion #128, . .. ) of the L2 table 72 are stored are individually managed by the L1table 73.

The L1 table 73 also include a plurality of data portions (a dataportion #0, a data portion #1, . . . ) having the same fixed size as thedata portions of the L3 table 71. In other words, the L1 table 73 isdivided into these data portions (the data portion #0, the data portion#1, . . . ).

Each data portion of the L1 table 73 includes a plurality of LUTentries, for example, 128 LUT entries. Each LUT entry shows a locationon the NAND flash memory 5 in which one data portion in the L2 table 72is stored. That is, 128² LBAs are covered by one LUT entry in the L1table 73.

The locations on the NAND flash memory 5 in which the data portions (thedata portion #0, the data portion #1, . . . ) of the L1 table 73 arestored are managed by system management information referred to as aroot table 74. The root table 74 may be loaded from the NAND flashmemory 5 to the RAM 6 when the SSD 3 receives power supply, for example,and from then on, the root table 74 may be constantly maintained on theRAM 6.

The root table 74 may include a plurality of entries. Each entryindicates a location on the NAND flash memory 5 in which one dataportion in the L1 table 73 is stored.

A translation target logical address is divided into four subfields,namely, a subfield 200A, a subfield 200B, a subfield 200C and a subfield200D.

Next, the logical-to-physical address translation processing to beexecuted by using the hierarchical lookup table shown in FIG. 11 will bebriefly described. Here, to simplify explanations, it is assumed thateach table is read from the NAND flash memory 5.

<Logical-to-Physical Address Translation at First Stage>

Firstly, the root table 74 is referred to by using the subfield 200A inthe translation target logical address, and a physical address (locationon the NAND flash memory 5) of a specific data portion in the L1 table73 is acquired. The specific data portion of the L1 table 73 is readfrom the NAND flash memory 5 based on the physical address.

Then, the specific data portion in the L1 table 73 is referred to byusing the subfield 200B, and one entry is selected from the specificdata portion in the L1 table 73. A physical address (location on theNAND flash memory 5) of one data portion in the L2 table 72 is stored inthe selected entry. The data portion of the L2 table 72 is read from theNAND flash memory 5 based on the physical address.

<Logical-to-Physical Address Translation at Next Stage>

Next, the data portion of the L2 table 72 is referred to by using thesubfield 200C in the translation target logical address, and one entryis selected from the data portion in the L2 table 72. A physical address(location on the NAND flash memory 5) of one data portion in the L3table 71 is stored in the selected entry. The data portion of the L3table 71 is read from the NAND flash memory 5 based on the physicaladdress.

<Address Translation at Final Stage>

Subsequently, the data portion in the L3 table 71 is referred to byusing the subfield 200D, and one entry is selected from the data portionin the L3 table 71. A physical address indicating a location on the NANDflash memory 5 in which variable-length data which is specified by alogical address included in a read request is stored, and a length ofthe variable-length data are stored in the selected entry. Thevariable-length data is read from the NAND flash memory 5 based on thephysical address and the length.

According to the configuration of this hierarchical lookup table, thesize of the storage region for storing this hierarchical lookup tablecan be reduced. It is because it is only necessary to secure storageregions corresponding to data portions in which physical addresses andlengths are actually stored on the NAND flash memory 5 or the RAM 6.

FIG. 12 shows an example of the hardware configuration of the SSD 3.

The SSD 3 includes a controller 4A and the NAND flash memory 5. The SSD3 may include a random access memory, for example, a DRAM 6A.

The NAND flash memory 5 includes a memory cell array where a pluralityof memory cells are arranged in a matrix. The NAND flash memory 5 may bea two-dimensional NAND flash memory or may be a three-dimensional NANDflash memory.

The memory cell array of the NAND flash memory 5 includes a plurality ofblocks BLK0 to BLKm−1. Each of the blocks BLK0 to BLKm−1 is formed of anumber of pages (here, pages P0 to Pn−1). The blocks BLK0 to BLKm−1function as erase units. The block may be referred to as a “physicalblock” or an “erase block”. Each of the pages P0 to Pn−1 includes aplurality of memory cells connected to the same word line. The pages P0to Pn−1 are data write/read units.

The controller 4A is an LSI configured to control the NAND flash memory5. The controller 4A is electrically connected to the NAND flash memory5 via a NAND interface 13 such as Toggle or Open NAND flash Interface(ONFI). The NAND interface 13 functions as a NAND control circuitconfigured to control the NAND flash memory 5.

The NAND flash memory 5 includes a plurality of NAND flash memory chips(dies) as shown in FIG. 13. The NAND flash memory chips can operateindependently from each other. Therefore, the NAND flash memory chipsfunction as parallel operation units. FIG. 13 shows a case where theNAND interface 13 is connected to 16 channels Ch.1 to Ch.16, and each ofthe 16 channels Ch.1 to Ch.16 is connected to two NAND flash memorychips. In this case, 16 NAND flash memory chips #1 to #16 connected tothe channels Ch.1 to Ch.16 may be formed as a bank #0, and the other 16NAND flash memory chips #17 to #32 connected to the channels Ch.1 toCh.16 may be formed as a bank #1. The banks function as paralleloperation units for operating a plurality of memory modules in parallelby bank interleaving. In the example of the configuration shown in FIG.13, a maximum of 32 NAND flash memory chips can be operated in parallelby 16 channels and the bank interleaving using two banks.

The controller 4A groups a plurality of blocks into a large unit(referred to as a “logical block” or a “superblock”). For example, onelogical block may include a total of 32 blocks which are selected fromNAND flash memory chips #1 to #32, respectively, but this is in no wayrestrictive. In FIG. 13, blocks having a hatch pattern represent blocks(physical blocks) included a certain logical block. Each NAND flashmemory chip can be identified by a channel number and a bank number.Further, each block (physical block) can be identified by a physicalblock number.

Note that the NAND flash memory chips #1 to #32 may have a multi-planeconfiguration. For example, if the NAND flash memory chips #1 to #32have such a multi-plane configuration that each of the NAND flash memorychips #1 to #32 has two planes, one logical block may include a total of64 blocks which are selected from 64 planes corresponding to the NANDflash memory chips #1 to #32, respectively.

Here, as shown in FIG. 14, it is assumed that a certain logical blockincludes 32 blocks (a block Blk2 in the NAND flash memory chip #1, ablock Blk3 in the NAND flash memory chip #2, a block Blk7 in the NANDflash memory chip #3, a block Blk4 in the NAND flash memory chip #4, ablock Blk6 in the NAND flash memory chip #5, . . . , a block Blk3 in theNAND flash memory chip #32).

In the case of writing data to this logical block, the controller 4A maywrite data in order from a page 0 of the block Blk2 in the NAND flashmemory chip #1, a page 0 of the block Blk3 in the NAND flash memory chip#2, a page 0 of the block Blk7 of the NAND flash memory chip #3, a page0 of the block Blk4 in the NAND flash memory chip #4, a page 0 of theblock Blk6 in the NAND flash memory chip #5, . . . , a page 0 of theblock Blk3 in the NAND flash memory chip #32. In this way, data can bewritten to a maximum of 32 pages in parallel. In the case of readingdata read from this logical block also, data can be read from a maximumof 32 pages in parallel.

The physical storage location managed by each LUT entry may berepresented by a logical block number, a block number (physical blocknumber) and a location in the block, may be represented by a logicalblock number, a block number (physical block number), a page number anda location in the page, or may be represented by a logical block numberand a location in the logical block.

Next, the configuration of the controller 4A shown in FIG. 12 will bedescribed.

The controller 4A may function as a flash translation layer (FTL)configured to execute data management and block management of the NANDflash memory 5. The data management executed by the FTL includes (1)management of mapping information indicating the correspondences betweenlogical addresses and physical addresses of the NAND flash memory 5, (2)processing for hiding a page-by-page read/write operation and ablock-by-block erase operation, etc. The logical address is an addresswhich the host 2 uses for specifying an address of the SSD 3. The LBA(logical block address (addressing)) is used as the logical address.

The mapping between the logical addresses and the physical addresses ismanaged by the variable-length LUT 32. The controller 4A manages themapping between the logical addresses and the physical addresses byusing the variable-length LUT. The variable-length LUT 32 may be loadedfrom the NAND flash memory 5 to the DRAM 6 when the SSD 3 is powered on.

The operation for writing data to a page can be performed only once inone erase cycle. Therefore, the controller 4A writes updated datacorresponding to a logical address not in a physical storage location inwhich previous data corresponding to the logical address is stored butin another physical storage location. Subsequently, the controller 4updates the variable-length LUT 32 and associates the logical addresswith the other physical storage location, and invalidates the previousdata.

The block management includes bad block management, wear leveling,garbage collection, etc. The wear leveling is the operation for levelingthe wear of blocks (physical blocks). In the garbage collection, toincrease the number of free blocks available for writing data, validdata are copied from some target blocks containing a mixture of validdata and invalid data to another block (for example, a free block).Here, the valid data means that the data is referred to from thevariable-length LUT 32 (that is, the data is tied with a logical addressas the latest data) and the data has a chance of being read by the host2 afterward. The invalid data means that the data no longer has a changeof being read by the host 2. For example, data which is associated witha logical address is the valid data, and data which is not associatedwith a logical address is the invalid data.

Subsequently, the controller 4 updates the lookup table (LUT) 32 andmaps the logical addresses of copied valid data to copy destinationphysical addresses, respectively. A block which only contains invaliddata after valid data have been copied to another block is released as afree block. In this way, after an erase operation, this block can bereused.

The controller 4A may include a host interface 11, a CPU 12, the NANDinterface 13, a DRAM interface 14, etc. The CPU 12, the NAND interface13 and the DRAM interface 14 may be connected to each other via a bus10.

The host interface 11 receives various commands from the host 2. Thecommands include a variable-length data write command and avariable-length data read command.

The CPU 12 is a processor configured to control the host interface 11,the NAND interface 13 and the DRAM interface 14. When the SSD 3 ispowered on, the CPU 12 loads control programs (firmware) stored in theNAND flash memory 5 to the DRAM 6 and executes the firmware, andperforms various processing. The CPU 12 can execute, for example,command processing for processing various commands from the host 2,etc., in addition to the above-described FTL processing. The operationof the CPU 12 is controlled by the above-described firmware executed bythe CPU 12. Note that part or all of the FTL processing and the commandprocessing may be executed by dedicated hardware in the controller 4.

The CPU 12 can function as a host request processing module 21A, avariable-length LUT management module 22A and a namespace managementmodule 23A. The host request processing module 21A executes the sameprocessing as the processing executed by the host request processingmodule 21 shown in FIG. 1. The variable-length LUT management module 22Aexecutes the same processing as the processing executed by thevariable-length LUT management module 22 shown in FIG. 1.

The namespace management module 23A executes the above-describedmulti-namespace control function. The namespace management module 23Acan create a namespace of a type #1 for handling fixed-length data and anamespace of a type #2 for handling variable-length data. Thelogical-to-physical address translation for the namespace of the type #1is executed by using the fixed-length LUT 33. The logical-to-physicaladdress translation for the namespace of type #2 is executed by usingthe variable-length LUT 32.

The DRAM interface 14 is a DRAM controller configured to execute accesscontrol of the DRAM 6. A storage region of the DRAM 6 is used forstoring the write buffer (WB) 31 and the LUTs 32 and 33.

Next, the configuration of the host 2 will be described.

The host 2 is an information processing device configured to executevarious programs. The programs executed by the information processingdevice include an application software layer 41, an operating system(OS) 42, a device driver 43, etc.

As is generally known, the operating system (OS) 42 is softwareconfigured to manage the whole host 2, control the hardware in the host2 and execute control to enable an application to use the hardware andthe SSD 3.

Various application software threads run on the application softwarelayer 41. For example, the application software threads include clientsoftware, database software, a virtual machine, etc.

If the application software layer 41 needs to transmit a request such asa read command or a write command to the SSD 3, the application softwarelayer 41 transmits the request to the OS 42. The OS 42 transmits therequest to the device driver 43. The device driver 43 translates therequest to a command (a read command, a write command, etc.). The drivedriver 43 transmits the command to the SSD 3. When receiving a responsefrom the SSD 3, the device driver 43 transmits the response to the OS42. The OS 42 transmits the response to the application software layer41.

A variable-length data read/write module 101A of the device driver 43executes the same processing as the processing executed by thevariable-length data read/write module 101 shown in FIG. 1.

FIG. 15 shows a plurality of regions managed by the controller 4A.

The controller 4A manages a plurality of regions in the NAND flashmemory 5, namely, a region #1, a region #2, . . . , a region #31, aregion #32 and a region #33. Each region can be realized by a namespace.Each namespace is a region of a kind (storage region) in the NAND flashmemory 5, and a logical address space (LBA space) is allocated. Eachnamespace is identified by an identifier of the namespace. If eachregion is realized by a namespace, an LBA range (LBA 0 to LBA n−1) isallocated to each region. The size of the LBA range (that is, the numberof LBAs) varies from region to region (from namespace to namespace).Each LBA range starts from an LBA 0.

For example, each of the region #1 (namespace NS#1), the region #2(namespace NS#2), . . . may be used for storing variable-length data.Further, the region #31 (namespace NS#31), the region #32 (namespaceNS#32) and the region #33 (namespace NS#33) may be used for storingfixed-length data.

FIG. 16 shows the relationships between a plurality of regions, logicaladdress spaces (LBA spaces) corresponding to these regions, and lookuptables corresponding to these regions.

A logical address space (LBA space) A1 with logical addresses from 0 ton−1 is allocated to the region #1 corresponding to the namespace NS#1. Alogical address space (LBA space) A2 with logical addresses from 0 ton−1 is allocated to the region #2 corresponding to the namespace NS#2. Alogical address space (LBA space) A31 with logical addresses from 0 ton−1 is allocated to the region #31 corresponding to the namespace NS#31.A logical address space (LBA space) A32 with logical addresses from 0 ton−1 is allocated to the region #32 corresponding to the namespace NS#32.A logical address space (LBA space) A33 with logical addresses from 0 ton−1 is allocated to the region #33 corresponding to the namespace NS#33.

In the present embodiment, the lookup table LUT is divided by region,i.e., by namespace. That is, logical-to-physical address translation forthe region #1 (namespace NS#1) is executed by using a variable-lengthLUT #1, and logical-to-physical address translation for the region #2(namespace NS#2) is executed by using a variable-length LUT #2. Further,logical-to-physical address translation for the region #31 (namespaceNS#31) is executed by using a variable-length LUT #31,logical-to-physical address translation for the region #32 (namespaceNS#32) is executed by using a variable-length LUT #32, andlogical-to-physical address translation for the region #33 (namespaceNS#33) is executed by using a variable-length LUT #33.

Arbitrary-length data can be written to an arbitrary logical address ineach of the region #1 (namespace NS#1) and the region #2 (namespaceNS#2).

As described above, according to the present embodiment, the SSD 3stores information indicating from which physical storage location onthe NAND flash memory 5 data is stored and in what length the data isstored, in the variable-length LUT 32, and in this way, arbitrary-lengthdata can be stored in a physical storage location corresponding to anarbitrary logical address. In other words, according to thevariable-length LUT 32, a physical storage region having a sizecorresponding to an arbitrary data length specified by the host 2 can beallocated to a physical storage location in the SSD 3 corresponding to acertain logical address.

Consequently, it is possible to solve inefficiency such as (1) anincrease of the processing time of the CPU of the host, (2) an increaseof the memory access time by reading/writing metadata, (3) an increaseof the consumption of a memory resource by wring metadata/dummy data,(4) an increase of write amplification by an increase of the consumptionof the memory resource, and (5) a reduction of the lifespan of the SSDby the increase of write amplification.

In the present embodiment, a NAND flash memory is described as anonvolatile memory. However, the function of the embodiment can also beapplied to various non-volatile memories such as a magnetoresistiverandom access memory (MRAM), a phase change random access memory (PRAM),a resistive random access memory (ReRAM) and a ferroelectric randomaccess memory (FeRAM).

Further, the SSD 3 may be used as one of a plurality of SSDs provided ina storage array. The storage array may be connected to an informationprocessing device such as a server computer via a cable or network. Thestorage array includes a controller which controls the SSDs in thestorage array. If the SSD 3 is applied to the storage array, thecontroller of the storage array may function as the host 2 of the SSD 3.

Further, a field for storing a flag indicating fixed-lengthdata/variable-length data may be added to each LUT entry. In this way,the read/write operation of variable-length data and the read/writeoperation of fixed-length data can be controlled by one LUT.

While certain embodiments have been described, these embodiments havebeen presented by way of example only, and are not intended to limit thescope of the inventions. Indeed, the novel embodiments described hereinmay be embodied in a variety of other forms; furthermore, variousomissions, substitutions and changes in the form of the embodimentsdescribed herein may be made without departing from the spirit of theinventions. The accompanying claims and their equivalents are intendedto cover such forms or modifications as would fall within the scope andspirit of the inventions.

What is claimed is:
 1. A memory system connectable to a host, the memorysystem comprising: a nonvolatile memory; and a controller electricallyconnected to the nonvolatile memory, the controller being configured to:manage a logical-to-physical address translation table including aplurality of entries corresponding to a plurality of logical addressesrespectively; receive, from the host, a write request specifying a firstlogical address and a length of first data, the first logical addressbeing associated with the first data; write the first data to thenonvolatile memory; and store, in an entry of the logical-to-physicaladdress translation table corresponding to the first logical address, afirst physical address and the length of the first data, the firstphysical address indicating a physical location of the nonvolatilememory to which the first data is written.
 2. The memory system of claim1, wherein the controller is further configured to: receive, from thehost, a read request specifying the first logical address; acquire thefirst physical address and the length from the logical-to-physicaladdress translation table; and read the first data from the nonvolatilememory on the basis of the acquired first physical address and theacquired length.
 3. The memory system of claim 1, wherein the physicallocation of the nonvolatile memory is represented by a block number of ablock in the nonvolatile memory and a location inside the block.
 4. Thememory system of claim 1, wherein the physical location of thenonvolatile memory is represented by a block number of a block in thenonvolatile memory, a page number of a page in the block, and a locationinside the page.
 5. The memory system of claim 1, wherein a length ofdata corresponding to a unit of each logical address is variable.
 6. Thememory system of claim 1, wherein when a first data portion of the firstdata is written to a first block of the nonvolatile memory and a seconddata portion of the first data is written to a second block of thenonvolatile memory, the controller is further configured to store afirst physical address, a length of the first data portion, a secondphysical address, and a length of the second data portion, in an entryof the logical-to-physical address translation table corresponding tothe first logical address, the first physical address indicating aphysical location of the first block to which the first data portion iswritten, the second physical address indicating a physical location ofthe second block to which the second data portion is written.
 7. Thememory system of claim 1, wherein the logical-to-physical addresstranslation table includes a first logical-to-physical addresstranslation table and a second logical-to-physical address translationtable, the first logical-to-physical address translation table includesan entry, the entry of the first logical-to-physical address translationtable including a location of the second logical-to-physical addresstranslation table and not including information as to a size of thesecond logical-to-physical address translation table, and the secondlogical-to-physical address translation table includes a plurality ofentries, each of the entries of the second logical-to-physical addresstranslation table including a logical address associated with data and alength of the data.
 8. The memory system of claim 1, wherein a physicalstorage region of the nonvolatile memory is allocated to the firstlogical address, and the physical storage region allocated to the firstlogical address has a size corresponding to the length of the firstdata.
 9. A method of controlling a nonvolatile memory, the methodcomprising: managing a logical-to-physical address translation tableincluding a plurality of entries corresponding to a plurality of logicaladdresses respectively; receiving, from a host, a write requestspecifying a first logical address and a length of first data, the firstlogical address being associated with the first data; writing the firstdata to the nonvolatile memory; and storing, in an entry of thelogical-to-physical address translation table corresponding to the firstlogical address, a first physical address and the length of the firstdata, the first physical address indicating a physical location of thenonvolatile memory to which the first data is written.
 10. The method ofclaim 9, further comprising: receiving, from the host, a read requestspecifying the first logical address; acquiring the first physicaladdress and the length from the logical-to-physical address translationtable; and reading the first data from the nonvolatile memory on thebasis of the acquired first physical address and the acquired length.11. The method of claim 9, wherein the physical location of thenonvolatile memory is represented by a block number of a block in thenonvolatile memory and a location inside the block.
 12. The method ofclaim 9, wherein the physical location of the nonvolatile memory isrepresented by a block number of a block in the nonvolatile memory, apage number of a page in the block, and a location inside the page. 13.The method of claim 9, wherein a length of data corresponding to a unitof each logical address is variable.
 14. The method of claim 9, furthercomprising: when a first data portion of the first data is written to afirst block of the nonvolatile memory and a second data portion of thefirst data is written to a second block of the nonvolatile memory,storing a first physical address, a length of the first data portion, asecond physical address, and a length of the second data portion, in anentry of the logical-to-physical address translation table correspondingto the first logical address, the first physical address indicating aphysical location of the first block to which the first data portion iswritten, the second physical address indicating a physical location ofthe second block to which the second data portion is written.
 15. Themethod of claim 9, wherein the logical-to-physical address translationtable includes a first logical-to-physical address translation table anda second logical-to-physical address translation table, the firstlogical-to-physical address translation table includes an entry, theentry of the first logical-to-physical address translation tableincluding a location of the second logical-to-physical addresstranslation table and not including information as to a size of thesecond logical-to-physical address translation table, and the secondlogical-to-physical address translation table includes a plurality ofentries, each of the entries of the second logical-to-physical addresstranslation table including a logical address associated with data and alength of the data.
 16. The method of claim 9, wherein a physicalstorage region of the nonvolatile memory is allocated to the firstlogical address, and the physical storage region allocated to the firstlogical address has a size corresponding to the length of the firstdata.